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CHAPTER  1 


INTRODUCTICW 


The  Ada  inplementation  described  eibove  was  tested  according  to  the  Ada 
Validation  Procedures  (Pro92]  against  the  Ada  Standard  (AdaS.'^l  using  the 
current  Ada  Compiler  Validation  Capability  (ACVC).  This  ValidatiC.i  ".irr'ai.y 
Report  (VSR)  gives  an  account  of  the  testing  of  this  Ada  implementation.  Foi. 
any  technical  terms  used  in  this  report,  the  reader  is  referred  to  [Pro92]. 
A  detailed  description  of  the  ACVC  may  be  found  in  the  current  ACVC  User's 
Guide  (UG89]. 


1.1  USE  OF  THIS  VALIDATION  SUMMARY  REPORT 

Consistent  with  the  national  laws  of  the  originating  country,  the  Ada 
Certification  Body  may  make  full  and  free  public  disclosure  of  this  report. 
In  the  United  States,  this  is  provided  in  accordance  with  the  "Freedom  of 
Information  Act"  (5  U.S.C.  #552).  The  results  of  this  validation  apply  only 
to  the  conpjters,  operating  systems,  and  conpiler  versions  identified  in  this 
report. 

The  organizations  represented  on  the  signature  page  of  this  report  do  not 
represent  or  warreuit  that  all  statements  set  forth  in  this  report  are 
accurate  auid  conplete,  or  that  the  subject  implementation  has  no 
nonconformities  to  the  Ada  Standard  other  than  those  presented.  Copies  of 
this  report  are  available  to  the  public  from  the  AVF  which  performed  this 
validation  or  from; 

National  Technical  Information  Service 
5285  Port  Royal  Road 
Springfield  VA  22161 

CJuestions  regarding  this  report  or  the  validation  test  results  should  be 
directed  to  the  AVF  v^ich  performed  this  validation  or  to: 

Ada  Validation  Organization 

Computer  and  Software  Engineering  Division 

Institute  for  Defense  Analyses 

1801  North  Beauregard  Street 

Alexandria  VA  22311-1772 
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1.2  REFERENCES 

[Ada83]  Reference  Manual  for  the  Ada  Proqramming  Language, 

ANSI/MIL-STD-lSl^,  February  1983  and  ISO  8652-1987. 

[Pro92]  Ada  Compiler  Validation  Procedures,  Version  3.1,  Ada  Joint 
Program  Office,  August  1992.  “ 

[UG89]  Ada  Compiler  Validation  Cape±>ilitv  User's  Guide,  21  June  1989. 


1.3  ACVC  TEST  CLASSES 

Conplieuice  of  Ada  inplementations  is  tested  by  meams  of  the  ACVC.  The  ACVC 
contains  a  collection  of  test  programs  structured  into  six  test  classes:  A, 
B,  C,  D,  E,  and  L.  The  first  letter  of  a  test  name  identifies  the  class  to 
vdiich  it  belongs.  Class  A,  C,  D,  and  E  tests  are  executadale.  Class  B  and 
class  L  tests  are  expected  to  produce  errors  at  compile  time  and  link  time, 
respectively. 

The  executable  tests  are  written  in  a  self-checking  memner  and  produce  a 
PASSED,  FAILED,  or  NOT  APPLICABLE  message  indicating  the  result  when  they  are 
executed.  Three  Ada  library  units,  the  packages  REPORT  and  SPPRT13,  and  the 
procedure  CHECK_FILE  are  used  for  this  purpose.  The  package  REPORT  also 
provides  a  set  of  identity  functions  used  to  defeat  some  compiler 
optimizations  allowed  by  the  Ada  Standard  that  would  circumvent  a  test 
objective.  The  package  SPPRT13  is  used  by  many  tests  for  Chapter  13  of  the 
Ada  Standard.  The  procedure  CHECK_F1LE  is  used  to  check  the  contents  of  text 
files  written  by  some  of  the  Class  C  tests  for  Chapter  14  of  tl;.2  Ada 
Standard.  The  operation  of  REPORT  and  CHECK_FILE  is  checked  by  a  set  of 
executeible  tests.  If  these  xaiits  are  not  operating  correctly,  validation 
testing  is  discontinued. 

Class  B  tests  check  that  a  conpiler  detects  illegal  leuiguage  usage.  Class  B 
tests  are  not  executable.  Each  test  in  this  class  is  compiled  and  the 
resulting  conpilation  listing  is  examined  to  verify  that  all  violations  of 
the  Ada  Standard  are  detected.  Some  of  the  class  B  tests  contain  legal  Ada 
code  which  must  not  be  flagged  illegal  by  the  compiler.  Ihis  behavior  is 
also  verified. 

Class  L  tests  check  that  an  Ada  inplementation  correctly  detects  violation  of 
the  Ada  Standard  involving  multiple,  separately  compiled  units.  Errors  are 
expected  at  link  time,  auid  execution  is  attempted. 

In  some  tests  of  the  ACVC,  certain  macro  strings  have  to  be  replaced  by 
implementation-specific  values  —  for  exanple,  the  largest  integer.  A  list 
of  the  values  used  for  this  inplementation  is  provided  in  Appendix  A.  In 
addition  to  these  anticipated  test  modifications,  additional  changes  may  be 
required  to  remove  unforeseen  conflicts  between  the  tests  and 
inplementation-dependent  characteristics.  The  modifications  required  for 
this  implementation  are  described  in  section  2.3. 
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For  each  Ada  implementation,  a  customized  test  suite  is  produced  by  the  AVF. 
This  customization  consists  of  making  the  modifications  described  in  the 
preceding  paragraph,  removing  withdravm  tests  (see  section  2.1),  and  possibly 
removing  some  inappliccible  tests  (see  section  2.2  and  (UG89]). 

In  order  to  pass  an  ACVC  an  Ada  implementation  must  process  each  test  of  the 
customized  test  suite  according  to  the  Ada  Standard. 


1.4  DEFINITION  OF  TERMS 

Ada  Compiler  The  software  and  euiy  needed  hardware  that  have  to  be  added  to 
a  given  host  and  target  con^niter  system  to  allow 
treunsformation  of  Ada  programs  into  executcdDle  form  and 
execution  thereof. 

Ada  Compiler  The  means  for  testing  conpliance  of  Ada  implementations. 
Validation  consisting  of  the  test  suite,  the  support  programs,  the  ACVC 
Capability  user's  guide  eind  the  tenplate  for  the  validation  summary 

(ACVC)  report. 

Ada  An  Ada  conpiler  with  its  host  computer  system  emd  its 

Implementation  target  computer  system. 

Ada  Joint  The  part  of  the  certification  body  vdiich  provides  policy  and 

Program  guidance  for  the  Ada  certification  system. 

Office  (AJPO) 

Ada  The  part  of  the  certification  body  which  carries  out  the 

Validation  procedures  required  to  establish  the  compliance  of  an  Ada 
Facility  (AVF)  implementation. 

Ada  The  part  of  the  certification  body  that  provides  technical 

Validation  guidance  for  operations  of  the  Ada  certification  system. 

Orgcinization 
(AVO) 

Compliance  of  The  ability  of  the  implementation  to  pass  an  ACVC  version, 
an  Ada 

Implementation 

Computer  A  functional  unit,  consisting  of  one  or  more  computers  and 

System  associated  software,  that  uses  common  storage  for  all  or  part 

of  a  program  and  also  for  all  or  part  of  the  data  necessary 
for  the  execution  of  the  program;  executes  user-written  or 
user-designated  programs;  performs  user-designated  data 
meuiipulation,  including  arithmetic  operations  and  logic 
operations;  and  that  can  execute  programs  that  modify 
themselves  during  execution.  A  computer  system  may  be  a 
stand-alone  unit  or  may  consist  of  several  inter-connected 
units. 
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Conformity 


Customer 


Declaration  of 
Conformance 


Host  Con?3uter 
System 

Inapplicable 

test 

ISO 

LRM 


Operating 

System 


Target 

Conputer 

System 

Validated  Ada 
Compi 

Validated  Ada 
Implementation 

Validation 


Withdrawn 

test 


Fulfillment  by  a  product,  process,  or  service  of  all 
requirements  specified. 

An  individual  or  corporate  entity  \dio  enters  into  an  agreement 
with  an  AVF  which  specifies  the  terms  and  conditions  for  AVF 
services  (of  any  kind)  to  be  performed. 

A  formal  statement  from  a  customer  assuring  that  conformity 
is  realized  or  attainable  on  the  Ada  implementation  for  which 
validation  status  is  realized. 

A  computer  system  v^ere  Ada  source  programs  are  transformed 
into  executable  form. 

A  test  that  contains  one  or  more  test  objectives  found  to  be 
irrelevant  for  the  given  Ada  implementation. 

International  Organization  for  Staundardization. 

The  Ada  standard,  or  Language  Reference  Manual,  published  as 
ANSI/MIL-STD-1815A-1983  and  ISO  8652-1987.  Citations  from  the 
LRM  take  the  form  "<section>.<subsection>:<paragraph> . " 

Software  that  controls  the  execution  of  programs  and  that 
provides  services  such  as  resource  allocation,  scheduling, 
input/output  control,  and  data  mamagement.  Usually,  operating 
systems  are  predominantly  software,  but  partial  or  complete 
hardware  implementations  are  possible. 

A  computer  system  vhere  the  executable  form  of  Ada  programs 
are  executed. 


The  coitpiler  of  a  validated  Ada  inplementation. 


An  Ada  implementation  that  has  been  validated  successfully 
either  by  AVF  testing  or  by  registration  (Pro92). 

The  process  of  checking  the  conformity  of  an  Ada  compiler  to 
the  Ada  programming  language  and  of  issuing  a  certificate  for 
this  implementation. 

A  test  found  to  be  incorrect  and  not  used  in  conformity 
testing.  A  test  may  be  incorrect  because  it  has  an  invalid 
test  objective,  fails  to  meet  its  test  objective,  or  contains 
erroneous  or  illegal  use  of  the  Ada  programming  leinguage. 
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2 . 1  WITHDRAWN  TESTS 

The  following  tests  have  been  withdrawn  by  the  AVO.  The  rationale  for 
withdrawing  each  test  is  available  from  either  the  AVO  or  the  AVF.  The 
publication  date  for  this  list  of  withdrawn  tests  is  22  November  1993. 


B27005A 

E28005C 

B28006C 

C32203A 

C34006D 

C35507K 

C35507L 

C35507N 

C35507O 

C35507P 

C35508I 

C35508J 

C35508M 

C35508N 

C35702A 

C35702B 

C37310A 

B41308B 

C43004A 

C45114A 

C45346A 

C45612A 

C45612B 

C45612C 

C45651A 

C46022A 

B49008A 

B49008B 

A54B02A 

C55B06A 

A74006A 

C74308A 

B83022B 

B83022H 

B83025B 

B83025D 

C83026A 

B83026B 

C83041A 

B85001L 

C86001F 

C9402LA 

CS7116A 

C98003B 

BA2011A 

CB7001A 

CB7001B 

CB7004A 

CC1223A 

BC1226A 

CC1226B 

BC3009B 

BD1B02B 

BD1B06A 

AD1B08A 

BD2A02A 

CD2A21E 

CD2A23E 

CD2A32A 

CD2A41A 

CD2A41E 

CD2A87A 

CD2B15C 

BD3006A 

BD4008A 

CD4022A 

CD4022D 

CD4024B 

CD4024C 

CD4024D 

CD4031A 

CD4051D 

CD5111A 

CD7004C 

ED7005D 

CD7005E 

AD7006A 

CD7006E 

An720lA 

AD7201E 

CD7204B 

AD7206A 

BD8002A 

BD8004C 

CD9005A 

CD9005B 

CDA201E 

CE2107I 

CE2117A 

CE2117B 

CE2119B 

CE2205B 

CE2405A 

CE3111C 

CE3116A 

CE3118A 

CE3411B 

CE3814A 

CE3412B 

CE3902B 

CE3607B 

CE3607C 

CE3607D 

CE3812A 

2.2  INAPPLICABLE  TESTS 


A  test  is  inapplicable  if  it  contains  test  objectives  v^ich  are  irrelevant 
for  a  given  Ada  implementation.  Reasons  for  a  test's  inapplicedaility  may  be 
supported  by  documents  issued  by  the  ISO  euid  the  AJPO  known  as  Ada 
Commentaries  and  commonly  referenced  in  the  format  Al-ddddd.  For  this 
implementation,  the  following  tests  were  determined  to  be  inapplicable  for 
the  reasons  indicated;  references  to  Ada  Commentaries  are  included  as 
appropriate. 
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Th,  following  201  tests  have  floating-point  type  declarations  requiting 
•iiore  digits  than  SYSTEM.MAX_DIGITS: 


C24113L..Y  (14  tests) 
C35706L..Y  (14  tests) 
C35708L..Y  (14  tests) 
C45241L..Y  (14  tests) 
C45421L..Y  (14  tests) 
C45524L..Z  (15  tests) 
C45641L..Y  (14  tests) 


C35705L..Y  (14  tests) 
C35707L..Y  (14  tests) 
C35802L..Z  (15  tests) 
C45321L..Y  (14  tests) 
C45521L..Z  (15  tests) 
C45621L..Z  (15  tests) 
C46012L..Z  (15  tests) 


The  following  21  tests  chec)t  for  the  predefined  type  SHORT_INTEGER;  for 
this  implementation,  there  is  no  such  type: 


C35404B 

C45412B 

C45611B 

B52004E 

CD7101E 


B36105C 

C45502B 

C45613B 

C55B07B 


C45231B 

C45503B 

C45614B 

B55B09D 


C45304B 

C45504B 

C45631B 

B86001V 


C45411B 

C45504E 

C45632B 

C86006D 


The  following  20  tests  check  for  the  predefined  type  LCX4G_INTEGER;  for 
this  implementation,  there  is  no  such  type: 


C35404C 

C45502C 

C45613C 

C55B07A 


C45231C 

C45503C 

C45614C 

B55B09C 


C45304C 

C45504C 

C45631C 

B86001W 


C45411C 

C45504F 

C45632C 

C86006C 


C45412C 

C45611C 

B52004D 

CD7101F 


C35404D,  C45231D,  B86001X,  C86006E,  and  CD7101G  check  for  a  predefined 
integer  type  with  a  name  other  than  INTEGER,  LONG_INTEGER ,  or 
SHORT_INTEGER;  for  this  implementation,  there  is  no  such  type. 


C35713B,  C45423B,  B86001T,  emd  C86006H  check  for  the  predefined  type 

SHORT_FLClAT ;  for  this  implementation,  there  is  no  such  type. 


C35713D  and  B86001Z  check  for  a  predefined  floating-point  type  with  a 
name  other  than  FLOAT,  La4G_FLQAT,  or  SHORT_FLOAT;  for  this 
implementation,  there  is  no  such  type. 


C45531M..P  and  C45532M..P  (8  tests)  check  fixed-point  operations  for 
types  that  require  a  SYSTEM. MAX_MANTISSA  of  47  or  greater;  for  this 
implementation,  MAX_MANTISSA  is  less  than  47. 


C45624A. .B  (2  tests)  check  that  the  proper  exception  is  raised  if 
MACHINE_OVERFLOWS  is  FALSE  for  floating  point  types  euid  the  results  of 
various  floating-point  operations  lie  outside  the  range  of  the  base 
type;  for  this  inplementation,  MACHINE_OVERFLCWS  is  TRUE. 


B86001Y  uses  the  name  of  a  predefined  fixed-point  type  other  than  type 
DURATION;  for  this  implementation,  there  is  no  such  type. 
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C96005B  uses  values  of  type  DURATICK's  base  type  that  are  outside  the 
reuige  of  type  DURATION;  for  this  implementation,  the  ranges  are  the 
same. 


LA3004A..B,  EA3004C..D,  eind  CA3004E..F  (6  tests)  check  pragma  INLINE  for 
procedures  2uid  functions;  this  implementation  does  not  support  pragma 
INLINE. 

CD1009C  checks  \4iether  a  length  clause  ccin  specify  a  non-default  size 
for  a  floating-point  type;  this  implementation  does  not  support  such 
sizes. 

CD2A84A,  CD2A84E,  CD2AB4I..J  (2  tests),  and  CD2A840  use  length  clauses 
to  specify  non-default  sizes  for  access  types;  this  implementation  does 
not  support  such  sizes. 

CD2B15B  checks  that  STORAGE  ERROR  is  raised  when  the  storage  size 
specified  for  a  collection  Ts  too  small  to  hold  a  single  value  of  the 
desi^ated  type;  this  implementation  allocates  more  space  than  was 
specified  by  the  length  clause,  as  allowed  by  AI-00558. 

BD8001A,  BD8003A,  BD8004A. .B  (2  tests),  and  AD8011A  use  machine  code 
insertions;  this  inplementation  provides  no  package  MACHINE_CODE . 

AE2101H,  EE2401D,  and  EE2401G  use  instantiations  of  package  DIRECT_IO 
with  unconstrained  array  types  and  record  types  with  discriminants 
without  defaults;  these  instantiations  are  rejected  by  this  compiler. 

The  tests  listed  in  the  following  table  check  that  USE  ERROR  is  raised 
if  the  given  file  operations  are  not  supported  for  the  given  combination 
of  mode  and  access  method;  this  implementation  supports  these 
operations. 

Test  File  Operation  Mode  File  Access  Method 


CE2102D 

CREATE 

IN  FILE 

SEQUENTIAL  10 

CE2102E 

CREATE 

OUT  FILE 

SEQUENTIAL  10 

CE2102F 

CREATE 

INOUT  FILE 

DIRECT  10 

CE2102I 

CREATE 

IN  FILE 

DIRECT  10 

CE2102J 

CREATE 

OUT  FILE 

DIRECT  10 

c:e2102n 

OPEN 

IN  FILE 

SEQUENTIAL  10 

CE2102O 

RESET 

IN  FILE 

SEQUENTIAL  10 

CE2102P 

OPEN 

OUT  FILE 

SEQUENTIAL  10 

CE2102Q 

RESET 

OUT  FILE 

SEQUENTIAL  10 

CE2102R 

OPEN 

INOUT  FILE 

DIRECT  10 

CE2102S 

RESET 

INOUT  FILE 

DIRECT  10 

CE2102T 

OPEN 

IN  FILE 

DIRECT  10 

CE2102U 

RESET 

IN  FILE 

DIRECT  10 

CE2102V 

OPEN 

OUT  FILE 

DIRECT  10 

CE2102W 

RESET 

OU'l'  FILE 

DIRECT  10 

CE3102E 

CREATE 

IN  FILE 

TEXT  10 

CE3102F 

RESET 

Any  Mode 

TEXT  10 

CE3102G 

DELETE 

TEXT  10 
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CE3102I  CREATE  OUT_FILE  TE>CT_IO 
CE3102J  OPEN  IN_FILE  TEXT_IO 
CE3102K  OPEN  OUT_FILE  TEXT_IO. 

CE2203A  checks  that  WRITE  raises  USE_ERROR  if  the  capacity  of  an 
external  sequential  file  is  exceeded;  this  iiqjlementation  cannot 
restrict  file  capacity. 

CE2403A  checks  that  WRITE  raises  USE_ERROR  if  the  capacity  of  an 
external  direct  file  is  exceeded;  this  inplementation  cannot  restrict 
file  capacity. 

CE3111B,  CE3111D..E  (2  tests),  CE3114B,  and  CE3115A  check  operations  on 
text  files  vrtien  multiple  internal  files  are  associated  with  the  same 
external  file  euid  one  or  more  are  open  for  writing;  USE_ERROR  is  raised 
v^en  this  association  is  attenpted. 

CE3304A  checks  that  SET_L1NE^LENGTH  and  SET  PAGE_LENGTH  raise  USE_ERROR 
if  they  specify  an  inapproprTate  value  for  Bie  external  file;  there  are 
no  inappropriate  values  for  this  implementation. 

CE3413B  checks  that  PAGE  raises  LAyOUT_ERROR  vdien  the  value  of  the  page 
number  exceeds  COUNT 'LAST;  for  this  implementation,  the  value  of 
COUNT' LAST  is  greater  than  150000,  maOiing  the  checking  of  this  objective 
impractical. 


2.3  TEST  MODIFICATIOIS 


Modifications  (see  section  1.3)  were  required  for  122  tests. 


The  following  tests  were  split  into  two  or  more  tests  because  this 
inplementation  did  not  report  the  violations  of  the  Ada  Standard  in  the  way 
expected  by  the  original  tests. 


E22003A 

B22005L 

B24001C 

B24204A 

B24205A 

B26002,\ 

B2A003B 

B2A005A 

B33201B 

B36002A 

B38009A 

B38103E 

B45205A 

B610C5A 

B67001H 

B83E01C 

B95003A 

BC1013A 

BC1206A 


B22003B 

B23002A 

B24005A 

B24204B 

B24206A 

B26005A 

B2A003C 

B2A005B 

B33202B 

B37106A 

B38009B 

B41201A 

B48002A 

B64006A 

B71001A 

B83E01D 

B95004A 

BC1109A 

BC1303F 


B22004A 

B23004A 

B24005B 

B24204C 

B242C6B 

B28003A 

B2A003D 

B2A007A 

B33203B 

B37205A 

B38103A 

B44001A 

B48002D 

B67001A 

B71001G 

B85008G 

B95063A 

BC1109B 

BC2001D 


B22004B 

B23004B 

B24007A 

B24204D 

B25002A 

B28003C 

B2A003E 

B2A021A 

B33301A 

B37307B 

B38103B 

B44004A 

B5100LA 

B67001B 

B71001M 

B85008H 

BAllOlE 

BC1109C 

BC2001E 


B22004C 

B24001A 

B24009A 

B24204E 

B25002B 

B29001A 

B2A003F 

B32103A 

B33301B 

B38003A 

B38103C 

B44004B 

B53003A 

B67001C 

B74104A 

B91001H 

BB1006B 

BC1109D 

BC3003B 


B22005K 

B24001B 

B24104A 

B24204F 

B26001A 

B2A003A 

B2A004A 

B3310LA 

B35101A 

B38003B 

B38103D 

B44004C 

B55A01A 

B67001D 

B74307B 

B95001D 

BB3005A 

BC1201A 

BC3005B 
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BC3013A  BD2B14A  BD2C14A  BE2210A  BE2413A 

BC3204D  and  BC3205C  were  graded  passed  by  Evaluation  Modification  as  directed 
by  the  AVO.  These  tests  are  expected  to  produce  compilation  errors,  but  this 
implementation  conpiles  the  units  without  error;  all  errors  are  detected  at 
link  time.  Ttiis  behavior  is  allowed  by  AI-00256,  as  the  units  are  illegal 
only  with  respect  to  units  that  they  do  not  depend  on. 

CE3804H  was  graded  passed  by  Evaluation  Modification  as  directed  by  the  AVO. 
This  test  requires  that  the  string  "-3.525"  ceui  be  read  from  a  file  using 
FLCiAT_IO  and  that  an  equality  comparison  with  the  nianeric  literal  '-3.525' 
will  evaluate  to  TRUE;  however,  because  -3.525  is  not  a  model  number,  this 
comparison  may  evaluate  to  FALSE  (LRM  4.9:12).  This  inpleraentation's 
compile-time  and  njn-time  evaluation  algorithms  differ;  thus,  this  check  for 
equality  fails  end  Report. Failed  is  called  at  line  61,  which  outputs  the 
message  "WIDTH  CHARACTERS  NOT  READ."  All  other  checks  were  passed. 
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3 


PROCESSING  INFORMATION 


3.1  TESTING  ENVIRONMENT 

The  Ada  inplementation  teste^  in  this  validation  effort  is  described 
adequately  hy  the  information  given  in  the  initial  pages  of  this  report. 

For  technical  and  sales  information  about  this  Ada  implementation,  contact: 

Jerry  Rudisin 

Rational  Software  Corporation 
2800  Seui  Tomas  Expressway 
Santa  Clara  CA  95051-0951 
(408)  496-3712 


Testing  of  this  Ada  inplementation  was  conducted  at  the  customer's  site  by  a 
validation  team  from  the  AVF. 


3.2  SUMMARY  OF  TEST  RESULTS 

An  Ada  Implementation  passes  a  given  ACVC  version  if  it  processes  each  test 
of  the  customized  test  suite  in  accordance  with  the  Ada  Programming  Language 
Standard,  \diether  the  test  is  applicable  or  inapplicable;  otherwise,  the  Ada 
Implementation  fails  the  ACVC  (Pro92]. 

For  all  processed  tests  (inapplicable  and  applicable),  a  result  was  obtained 
that  conforms  to  the  Ada  Programming  Language  Standard. 

The  list  of  items  below  gives  the  number  of  ACVC  tests  in  various  categories. 
All  tests  were  processed,  except  those  that  were  withdrawn  because  of  test 
errors  (item  b;  see  section  2.1),  those  that  require  a  floating-point 
precision  that  exceeds  the  inplementation's  naximum  precision  (item  e;  see 
section  2.2),  emd  those  that  depend  on  the  support  of  a  file  system  —  if 
none  is  supported  (item  d).  Ail  tests  passed,  except  those  that  are  listed 
in  sections  2.1  and  2.2  (counted  in  items  b  and  f,  below). 
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a)  Total  Number  of  Applicable  Tests  3750 

b)  Total  Number  of  Withdrawn  Tests  104 

c)  Processed  Inapplicable  Tests  115 

d)  Non-Processed  I/O  Tests  0 

e)  Non-Processed  Floating-Point 

Precision  Tests  201 

f)  Total  Number  of  Inapplicable  Tests  316  (c+d+e) 


g)  Total  Number  of  Tests  for  ACVC  1.11  4170  (a+bff) 


3 . 3  TEST  EXECUTION 

A  magnetic  tape  containing  the  customized  test  suite  (see  section  1.3)  was 
taken  on-site  by  the  validation  team  for  processing.  Hie  validation  tape  was 
loaded  on  a  machine  acting  as  a  file  server.  The  files  were  accessed  via 
automounted  NFS. 


After  the  test  files  were  loaded  onto  the  host  computer,  the  full  set  of 
tests  was  processed  by  the  Ada  inplementation. 

The  tests  were  coitpiled,  linked  and  executed  on  the  host  computer  system. 
The  results  were  captured  on  the  host  computer  system. 

Testing  was  performed  using  command  scripts  provided  by  the  customer  and 
reviewed  by  the  validation  team.  See  Appendix  B  for  a  complete  listing  of 
the  processing  options  for  this  inplementation.  It  also  indicates  the 
default  options.  The  options  invoked  explicitly  for  validation  testing 
during  this  test  were: 


Option  I  Switch 
-listing_di rectory  <dir> 

-conpile 


Effect 

To  produce  a  listing  in  the  specified 
directory  <dir>. 

TO  syntactically  and  semantically  analyze  a 
source  file  and  produce  an  Ada  unit  (or 
units)  if  correct. 


-goal  linked 


Produce  the  object  code  and  linked 
executable  for  an  Ada  main  program. 


Test  output,  conpiler  and  linker  listings,  and  job  logs  were  captured  on 
magnetic  tape  and  archived  at  the  AVF.  The  listings  examined  on-site  by  the 
validation  team  were  also  archived. 
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MACRO  PARAMETTERS 


This  af^ndix  contains  the  macro  parameters  used  for  customizing  the  ACVC. 
The  meaning  emd  purpose  of  these  parameters  are  explained  in  [UG89].  The 
parameter  values  are  presented  in  two  tables.  The  first  table  lists  the 
values  that  are  defined  in  terms  of  the  maximum  input-line  length,  which  is 
the- value  for  $MAX_IN_LEN— also  listed  here.  These  values  are  expressed  here 
as  Ada  string  aggregates,  vhere  "V"  represents  the  meueimum  input-line  length. 

Macro  Parameter  Macro  Value 


$MAX_1N_LEN 

254  —  Value  of  V 

$BIG_ID1 

(1..V-1  =>  '’AS  V  ->  'V) 

$BIG_1D2 

(1..V-1  ->  'A',  V  ->  '2' ) 

$BIG_ID3 

(1..V/2  ->  'A' )  &  '3'  & 
(1..V-1-V/2  ->  'A') 

$BIG_ID4 

(1..V/2  ->  'A')  &  '4'  & 
(1..V-1-V/2  ->  'A') 

$BIG_INT_LIT 

(1..V-3  ->  '0')  &  "298" 

$BIG_REAL_LIT 

(1..V-5  ->  '0')  &  "690.0" 

$BIG_STRING1 

&  (1..V/2  ->  'A' )  & 

$BIG_STRING2 

&  (1..V-1-V/2  ->  'A')  &  '1 

$BLANKS 

(1..V-20 

$MAX  LEN  INT  BASE3)  LITERAL 

~  “  “  "2;"  &  (l,.V-5  ->  '0')  &  "11:" 

$MAX  LEN  REAL  BASED  LITERAL 

~  “  ~  "16:"  &  (1..V-7  ->  '0')  &  "F.E:" 
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$MAX_STRING_LITE3W^  &  (1..V-2  ->  'A')  & 

The  following  table  lists  all  of  the  other  macro  parameters  and  their 
respective  values. 

Macro  Parameter  Macro  Value 


$ACC_SIZE 

32 

$ALIGNMENT 

1 

$COUNT_LAST 

1000000000 

$DEFAULT_MEM_SIZE 

2147483647 

$DEFAULT_STOR_UNIT 

8 

$DEFAULT_SYS_NAME 

RS6000_AIX 

$DELTA_DOC 

0.000_000_000_465 

661_287_307_739_257_812_5 

$ENTRY_ADDRESS 

SYSTEM . TO_ADDRESS 

(30) 

$ENTRY_ADDRESS1 

SYSTEM . TO_ADDRESS 

(31) 

$ENTRY_ADDRESS2 

SYSTEM . TO_ADDRESS 

(2) 

$F1ELD_LAST 

2147483647 

$F1LE_TERMINAT0R 

f  r 

$FIXED_NAME 

NO_SUCH_TYPE 

$FLCIAT_NAME 

NO_SUCH_TYPE 

$FORM_STRING 

If  If 

$F0RM_STRING2 

"CANNOT_RESTRICT_ 

FILE_CAPACITY" 

$GREATER  THAN  DURATION 

1.0 

$GREATER  THAN  DURATICW  BASE  LAST 

T31_073.0 

$Ca^TER  THAN  FLOAT  BASE  LAST 

1.T^E308 

$aREATER_THAN_FLQAT_ 

SAFE  LARGE 
■  3.IE38 
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$GREATER  THAN  SHORT  FLOAT  SAFE  LARGE 

1.0E308  ~ 

$HIGH_PRIORITy  255 

$ ILLEGAL_EXTERNAL_FILE_NAME1 

BAD/_CHARACTERS 

$ILLEGAL_EXTERNAL_FILE_NAME2 

CONTAINS/JWILDCARDS 

$INAPPROPRIATE  LINE  LENGTH 

-1 

$INAPPROPRIATE_PAGE_LENGTH 

-1 

$INCLUDE_PRAGMA1  PRAGMA  INCLUDE  ( "A28006D1.TST" ) ; 

$INCLUDE_PRAGMA2  PRAGMA  INCLUDE  ( "B28006D1 .TST" ) ; 

$INTEGER_FIRST  -2147483648 

$INTEGER_LAST  2147483647 

$INTEGER_LAST_PLUS_1  2147483648 

$INTERFACE_LANGUAGE  C 

$LESS_THAN_DURATION  -1.0 

$LESS_THAN_DURATION_BASE  FIRST 

-lll_073.0 

$LINE_TERMINATOR  ASCI I . LF 

$LOW_PRIORITY  0 

$MACHINE_CODE_STATEMENT 

NULL; 

$MACHINE_CODE_'m'E  NO_SUCH_TYPE 

$MANTISSA_DOC  31 

$MAX_DIGITS  15 

$MAX_INT  2147483647 

$MAX_INT_PLUS_1  2147483648 

$MIN_INT  -2147483648 

$NAME  NO  SUCH  TYPE 
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$NAME_LIST 

RS6000_AIX 

$NAME_SPECIFICATI0N1 

X2120A 

$NAME_SPECIFICATI0N2 

X2120B 

$NAME_SPECIFICATIC»I3 

X3il9A 

$NEG_BA3ED_INT 

16#FFFFFFFE# 

$NEW_MEM_SIZE 

2147483647 

$NEW_STOR_tINIT 

8 

$NEW_SYS_NAME 

RS6000_AIX 

$PAGE_TERMINATOR 

ASCII.FF 

$RECORDJDEFINITI<»I 

NEW  INTEGER; 

$RECORD_NAME 

NO_SUCH_MACHINE_CODE_TYPE 

$TASK_SIZE 

32 

$TASK_STORAGE_SIZE 

8192 

$TICK 

(1.0/100.0) 

$VARIABLE_ADDRESS 

FCNDECL.AE©RESSO 

$VARIABLE_ADDRESS1 

FCNDECL . ADDRES51 

$VARIABLE_ADDRESS2 

FCNDECL.ADDRESS2 

$Y0UR_PRA£31A 

EXPORT_OBJECT 
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COMPILATICW  AND  LINKER  OPTIONS 


The  con^jiler  and  linker  options  of  this  Ada  implementation,  as  described  in 
this  ^pendix,  are  provided  by  the  customer,  unless  specifically  noted 
otherwise,  references  in  this  appendix  are  to  compiler  documentation  and  not 
to  this  report. 
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APPENDIX  C 

APPENDIX  F  OF  THE  Ada  STANDARD 


The  only  allowed  inplementation  dependencies  correspond  to 
implementation-dependent  pragmas,  to  certain  machine-dependent  conventions  as 
mentioned  in  Chapter  13  of  the  Ada  Standard,  and  to  certain  allowed 
restrictions  on  representation  clauses.  The  implementation-dependent 
characteristics  of  this  Ada  inplementation,  as  described  in  this  Appendix, 
are  provided  by  the  customer.  Unless  specifically  noted  otherwise, 
references  in  this  Appendix  are  to  compiler  documentation  and  not  to  this 
report.  Inplementation-specific  portions  of  the  package  STANDARD,  which  are 
not  a  part  of  Appendix  F,  are; 


package  STANDARD  is 

type  Integer  is  range  -2147483648  ..  2147483647; 

type  Float  is  digits  6 

range  -3.40282E+38  ..  3.40282E+38; 

type  Long_Float  is  digits  15 

range  -1.79769313486231E+308  ..  1.79769313486231E+308; 

type  Duration  is  delta  0.000061035156 

range  -131072.00000000  ..  131071.9999389648437500000000; 

end  STANDARD; 
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Chapter  10 


LRM  Appendix  F:  Implementation- 
Dependent  Characteristics 


This  chapter  provides  information  as  required  by  the  LRM 
Appendix  F.  The  Implementation-dependent  characteristics  of 
Rational  Ada  are  described  In  the  following  sections: 

■  “Pragmas”  on  page  79 

■  “Attributes”  on  page  101 

■  “Packages  Standard  and  System”  on  page  105 

■  “Representation  Clauses”  on  page  108 

■  “Implementation-Generated  Neunes”  on  page  110 

■  “Address  Clauses  (LRM  13.5)"  on  page  111 

■  “Unchecked  Programming”  on  page  111 

■  “Input/Output  Packages”  on  page  1 12 

■  “Other  Implementation-Dependent  Features"  on  page  1 1 4 


Pragmas _ _ 

This  section  provides: 

■  General  notes  about  pragma  error  handling 

■  A  table  of  Implementation  dependencies  in  the  predefined 
pragmas  from  LRM  Annex  B 

■  A  table  of  implementation-defined  pragmas 

■  Detailed  descriptions  of  each  of  the  implementation-defined 
pragmas  starting  on  page  83 

Error  Handling  for  Pragmas 

A  pragma  whose  existence,  placement,  or  arguments  do  not 
correspond  to  those  allowed  Is  Ignored,  by  default,  by  the 
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compiler  and  the  runtime  system.  This  means  that  a  warning 
is  generated  if  the  compiler  detects  such  eui  error,  but  in  ziny 
event  the  compilation  completes  successfully. 

Several  Apex  context  switches  allow  you,  however,  to  specify 
whether  to  treat  certain  classes  of  invalid  pragmas  as  errors 
that  prevent  successful  compilation  rather  than  as  warnings. 
See  Appendix  A,  “Switches,"  for  details  on  the  following 
switches: 

m  ReJect_Bad_Lrm_Pragmas:  Affects  the  handling  of  illegal 
LRM -defined  pragmas 

■  ReJect_Bad_Ratlonal_Pragmas:  Affects  the  handling  of 
illegal  Rational  implementation-defined  pragmas 

■  ReJect  Undefined  Pragmas:  Affects  the  handling  of 
pragmas  defined  neither  in  the  LRM  nor  in  this  Appendix  F 

If  more  than  one  of  the  same  pragma  is  specified  where  it  Is  not 
appropriate  to  do  so  (for  example,  two  pragma  Mains  on  the 
same  unit),  the  first  one  is  used  and  the  others  generate 
warnings  at  compile  time. 

References 

■  pragma  warnings,  LRM  2.8(9),  2.8(  1 1) 

Predefined  Pragmas 

For  each  pragma  defined  in  Annex  B  of  the  LRM,  Table  1 0- 1 
describes  the  extent  to  which  Rational  Ada  supports  it. 


Table  10-1  Predejbied  Pragmcu  from  LRM  Annex  B 


Predefined 

Pragma 

Level  of  Support 

Controlled 

Always  implicitly  In  effect  because  the  implementa¬ 
tion  does  not  support  automatic  garbage  collection 

Elaborate 

As  described  in  Annex  B 

Inline 

Has  no  effect 

Interface 

As  described  In  Annex  B:  must  be  used  in  conjunc¬ 
tion  with  pragmas  Import  Procedure  and  Import- 
_Fu  notion 
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Tablm  10-1  Prade/lnad  Pragmas  from  LBM  Annex  B  (Continued) 
Predefined 

Pragma  Level  of  Support _ 

List  As  described  In  Annex  B 


Memory_Slze 

Optimize 


Pack 

Page 

Priority 

Shared 

Storage_Unlt 

Suppress 

System_Name 


Has  no  effect 

Has  an  effect  only  when  located  In  the  outermost 
scope,  where  it  applies  to  the  entire  compilation  unit: 
if  not  used,  the  value  SPACE  is  assumed.  See  “Set¬ 
ting  the  Optimization  Objective’  on  page  2 1 

As  described  in  Annex  B:  see  “Concepts  for  Object 
Sizes’  on  page  67 

As  described  in  Annex  B 

As  described  In  Annex  B  and  LRM  6.8(2);  the  default 
is  127 

As  given  in  Annex  B:  has  an  effect  only  for  integer, 
enumeration,  access,  and  fixed  types 

Has  no  effect 

As  described  in  Annex  B 

Has  no  effect  (there  Is  only  one  enumeration  literal  in 
the  type  System.System_Name) _ 


Implementation-Defined  Pragmas 

Table  10-2  summarizes  all  implementation -defined  pragmas  in 
Rational  Ada.  Each  pragma  is  described  in  more  detail  in  the 
following  subsections. 
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TatU  10-2  Implmmtation-DeJlnKd.  Pragmas 


Implementation* 
Defined  Pragma 

Description 

Assert 

Raises  an  exception  if  a  specified  Boolean 
expression  evaluates  to  False  at  run  time 

Collectlon_PoUcy 

Controls  memory  allocation  for  the  collec¬ 
tion  designated  by  an  access  type 

Export_Functlon 

Creates  a  global  symbol  for  an  Ada  function 
so  that  it  ran  be  called  by  non-Ada  code 

Export  Object 

Creates  a  global  symbol  for  an  Ada  object  so 
that  it  can  be  referenced  by  non -Ada  code 

ExportProcedure 

Creates  a  global  symbol  for  an  Ada  proce¬ 
dure  so  that  it  can  be  called  by  non -Ada 
code 

Generlc_Pollcy 

Tells  the  compiler  how  to  generate  code  for  a 
generic  and  its  instantiations 

Im  port_Fu  ncUon 

Associates  the  global  symbol  for  a  non-Ada 
function  with  an  Ada  name  so  that  an  Ada 
subprogram  can  call  the  function 

Iinport_Object 

Associates  the  global  symbol  for  a  non-Ada 
object  with  an  Ada  name,  so  that  an  Ada 
subprogram  can  reference  the  object 

Im  port  _P  roced  u  re 

Associates  the  global  symbol  for  a  non-Ada 
procedure  with  an  Ada  name,  sc  that  an  Ada 
subprogram  can  call  the  procedure 

Initialize 

Specifies  that  default  initialization  be  car¬ 
ried  out  for  an  imported  object  or  an  object 
referenced  by  an  address  clause 

InstancePollcy 

Specifies  replicated  code  for  specific  instan¬ 
tiations  of  a  shared -code  generic 

Main 

Designates  an  Ada  main  unit  and  specifies 
aspects  of  its  run-time  behavior 

Must_Bc_Cons  trained 

Indicates  whether  formal  private  and  limited 
private  types  within  a  generic  formal  part 
must  be  constrained 
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Tablm  10-2  Implementation-D^nmd  Pragmaa  (Continued) 


Implementation- 
Defined  Pragma 

Description 

Slgnal_Handler 

Inatalh  a  procedure  as  a  UNIX  signal 
handler 

Suppress_All 

Suppresses  all  permitted  runtime  checks 

SuppressElaboration- 

_Checks 

Suppresses  elaboration  checks  for  a  specific 
compilation  unit 

Pragma  Assert 

Raises  an  exception  if  a  specified  Boolean  expression  evaluates 
to  False  at  run  time.  The  syntax  is: 

pragma  ASSKRX 

( (PRCDZCATE  *>]  hool»aD_»xpreami.aa)  t 

Arguments 

■  Predicate:  The  Boolean  expression  to  be  evaluated  at  run 
time. 

Usage 

When  the  pragma  is  encountered  at  run  time,  the  Boolean 
expression  is  evaluated.  If  the  result  is  Fadse,  the  System.Asser- 
tlon_Error  exception  is  raised;  if  the  result  is  True,  no  action  is 
taken. 

This  pragma  can  appear  anywhere  that  a  declaration  or  state¬ 
ment  is  allowed. 

Pragma  Collection_Policy 

Controls  memory  allocation  for  the  collection  designated  by  an 
access  type.  The  syntax  is: 

pragma  COU.ECTZOH_Paz.ICT 


(ACCE8S_TTPB 

ace«aa_typ« , 

ZHZTZA1._8ZXB 

■> 

iatagar_*xpraaaion 

I. 

EXTBI8ZBI.B 

-> 

heoiMfl_arprMsioa  ] 

I. 

EZT1H8Z(»_8ZXE 

«> 

iateg»r_axpremmioa] ) ; 
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Arguments 

■  Accass_T7p«:  The  access  type  on  which  to  perform  storage 
management. 

■  Znltial_slse:  The  size  In  storage  vinits  of  the  initial  collec¬ 
tion  that  is  created  for  an  access  type.  A  n^ative  value  is 
treated  as  0. 

■  Extensible:  Spiecifles  sdiether  the  collection  can  be 
extended.  If  True,  sets  the  extension  size  to  the  default  or 
specified  value  of  Extenslon_Slze;  otherwise.  Extension  Size 
is  ignored.  The  default  value  is  True. 

m  Eztansion_Slse:  The  minimtim  number  of  storage  units 
by  which  the  collection  will  be  extended,  when  needed,  if  it 
is  extensible.  A  negative  value  is  treated  as  0.  The  default 
value  is  4,096  bytes. 

Usage 

The  pragma  must  appear  in  the  same  declarative  region  as  the 
access  type  to  which  it  applies,  after  the  access  t>'pe’s  declara¬ 
tion  and  before  any  forcing  occurrence  of  the  access  type.  If  the 
access  type  is  a  private  type,  the  pragma  must  appear  in  the 
private  part  after  the  complete  access-type  declaration.  If  the 
pragma  appears  outside  the  specified  areas,  it  is  Ignored. 

A  description  and  example  of  the  pragma’s  application  are 
provided  in  “Managing  Storage  for  Access  Types"  on  page  63. 

Notes 

■  The  arguments  must  be  specified  using  named  association. 

■  Only  one  Collectlon  Pollcy  pragma  is  allowed  pjer  access 
type.  If  more  than  one  is  specified,  the  first  is  applied  and 
the  rest  are  ignored. 

■  When  an  access  type  has  an  associated  Storage  Size 
clause,  any  Collection_Policy  pragma  for  that  access  type  is 
ignored.  This  occurs  because  a  statement  of  the  form: 

for  Z'S10lwaE_8IZE  uoo  mimmf 

is  functionally  equivalent  to: 
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prmgmm  COLLBCTKM.POLICT 


(ACC188_TXPB 

•> 

X, 

XHXTZAL_8IXE 

•> 

mi*», 

EXmSXBU 

PAX.8B); 

■  If  Inltlal_Size  is  nonpositive  and  Extensible  is  False, 
attempting  to  execute  an  allocator  of  the  access  type  raises 
the  Storage_EiTor  exception. 

References 

■  access  type,  LRM  3.8 

■  allocator.  LRM  4.8 

■  collection,  LRM  3.8 

■  forcing  occurrence,  LRM  13. 1(6) 

■  Storage  Error.  LRM  11.1 

■  Storage  Slze,  LRM  13.7.2 

Pragmas  Export_Functlon,  Export_Ob]ect,  and  Export_Procedure 

Creates  a  global  symbol  for  an  Ada  subprogram  (function  or 
procedure)  or  object  so  that  it  can  be  called  or  referenced  by 
non-Ada  code.  The  syntax  is; 

pragma  EZPORT.rUMCTXOa 


( [XMTERHAL 

•>1 

iatarnai_i>ama 

I. 

(EZTEiaiAI. 

->J 

"  •ztamai_JiaBa” ) 

1, 

(  PA]UUIETER_TZPB8 

->1 

pmram»t*r_typ«_list] 

1. 

[RE8ULT_TTPE 

->1 

typ»_mark] 

1. 

[XJurouxoE 

*>J 

i4uiguaga_nama) ) ; 

pragma 

EZPORT_OBJECT 

([ISTCaHAL  »)  iatamai^naM 
(  ,  [CXTEiaiAL  ->]  *axtamai_oaaa''  ]  )  ; 


pragma  CXPORT_PIIOCCDtlIUC 
(  [XMTERMiU. 

->1 

iatarnaJ_flama 

1. 

(CXTEIOIAL 

->1 

* •xtmrBal_nam»" ] 

1, 

( PARANEIER.TTPES 

->J 

parama t ar_ t jpa_  i i a t  ] 

1, 

[UWOUItOE 

->1 

JaDguaga_naiiw] ) ; 
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Arguments 

a  Internal:  The  Ada  simple  name  of  the  Ada  subprogram  or 
object  to  be  exported.  For  functions,  this  can  also  be  an 
operator  symbol. 

a  External:  An  optional  string  literal  that  specifies  the  global 
symbol  name  to  be  created  by  the  Ada  compiler.  This  name 
must  obey  the  naming  conventions  for  the  host  operating 
system's  object-module  format,  and  therefore  it  may  differ 
from  the  Internal  subprogram  or  object  name.  If  am  external 
naune  is  not  specified,  the  Internad  name  is  used  for  the 
symbol  name. 

a  ParaBiatar_Typas:  A  parenthesized,  comma -separated  list 
of  type  aind/or  subtype  naunes  that  describes  the  paraim- 
eter-type  profile  of  an  exported  subprogram.  If  the  subpro¬ 
gram!  has  no  pauameters,  the  list  cam  consist  of  the  single 
word  Null.  This  optionad  augument  may  be  required  when 
the  Internad  argument  specifies  an  overloaded  subprogram. 
See  “Usage,"  below. 

a  Result_Typ«:  The  result-lype  profile  of  an  exported 

function.  This  optional  argument  may  be  required  when  the 
Internad  airgument  specifies  an  overloaded  function.  See 
“Usage,"  below. 

a  Language:  The  natme  of  the  lamguage  in  which  the  calling 
code  is  written.  The  only  lamguage  name  currently 
supported  is  C;  adways  use  this  value  when  expxDrting  to  C 
or  C++.  Other  lamguaige  naunes  aue  Ignored,  so  this 
au-gument  cam  be  omitted  when  exporting  to  a  lamguage 
other  tham  C  or  C++. 

Usage 

Use  these  export  praigmas  to  create  global  symbolic  names  for 
Ada  subprograms  that  will  be  cadled — or  Ada  objects  that  will  be 
refereno^ — from  non-Ada  code.  The  linker  will  use  these 
symbols  to  resolve  intermodule  references. 

If  the  Internal  subprogram  name  is  overloaded,  you  must 
supply  enough  information  for  the  compder  to  determine 
unaunbiguously  which  subprogram  to  export.  Specify  the 
Paramieter  Typcs  (amd/or,  for  functions,  the  Result  Type)  so 
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that  the  compiler  can  construct  the  parameter-  and/or  result- 
type  profile  of  the  subprogram 


CcaUlorv  E^orting  a  subprogram  does  not  export  the  mecha¬ 
nism  used  by  the  compiler  to  perform  elaboration  checks.  A  call 
from  another  language  to  an  exported  subprogram  with  an 
unelaborated  body  may  produce  unpredictable  results  when  the 
subprogram  rrferences  on  object  that  Is  Itself  unelaborated. 


Caution:  Accesses  to  Ada  objects  by  non-Ada  code  are  inher¬ 
ently  unsafe:  the  compiler  and  runtime  system  cannot  guarantee 
the  Integrity  of  such  exported  objects.  It  Is  the  developer  's  respon¬ 
sibility  to  ensure  that  the  code  that  accesses  an  exported  object 
properly  interprets  and  maintains  the  underlying  structure  of  the 
object 


Notes 

a  An  export  The  pragma  can  appear  only  at  the  place  of  a 
declarative  Item  in  a  declarative  part  or  package  specifica¬ 
tion;  the  subprogram  or  object  to  which  it  applies  must 
have  been  declared  by  an  earlier  declarative  item  of  the 
same  declarative  part  or  package  specification, 
a  An  exported  subprogram  must: 

□  Not  be  a  generic 

□  Be  declared  in  a  static  scope:  that  is.  it  must  not  be 
inside  any  subprogram,  task,  generic  unit,  or  block 
statement 

a  An  exported  object  must: 

□  Not  be  in  a  generic  unit 

□  Be  a  variable 

□  Be  declared  in  a  static  scope;  that  is.  it  must  not  be 
inside  any  subprogram,  task,  generic  unit,  or  block 
statement 

□  Have  a  static  size;  that  is.  its  subtype  must  be  one  of; 

-  A  scalar  type  or  subtype 

-  An  array  subtype  with  static  index  constraints  whose 
component  size  is  static 

-  An  imdiscrimlnated  record  type  or  subtype 
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References  for  Subprograms 

■  elaboration  of  a  library  nnlr.  LRM  10.5 

a  order  of  elaboration.  LRM  3.9 

■  overloading,  LRM  8.3 

■  parameter  and  result  type  profile,  LRM  6.6 

■  “Calling  an  Ada  Subprogram  fi'om  C  on  page  8 

References  for  Objects 

■  limited  private  type.  LRM  7.4.4 

■  private  type,  LRM  7.4 

■  “Sharing  Global  Objects”  on  page  1 4 

Pragma  Generic_Policy 

Tells  the  compiler  how  to  generate  code  for  a  generic  package  or 

subprogram  and  its  instantiations.  The  syntax  is: 

prsgM  OntSRXC_P01.1CX 

( [OiamZC_UMIT->)  mxmpl»_aam0, 

(CODB  «>}  REPLICATED  j  SHARED); 

Arguments 

■  6«nsric_Uoit:  The  simple  name  of  the  generic  package  or 
subprogram  to  which  the  pragma  applies. 

■  Code:  A  keyword  that  specifies  whether  edl  instantiations 
should  share  the  code  In  one  common  routine  (Shared),  or 
whether  each  Instantiation  should  be  coded  separately 
(Replicated). 

Usage 

See  "Setting  Shared  or  Replicated  Generic  Policy”  on  page  22. 

Notes 

■  Use  pragma  Instancc  Policy  to  override  the  shared  Generic- 

Policy  for  one  or  more  instantiations  of  a  generic  package 
or  subprogram.  See  “Pragma  Instance  Policy”  on  page  93. 

■  The  compiler  treat  all  generics  as  Replicated  unless  other¬ 
wise  specified  with  pragma  Generic  Policy. 


88 


7x9’  Printed  Template,  rev.  1 . 9 


Pragmas:  Pragmas  lmport_Function,  lmport_Object,  and  lmport_Procedure 


■  The  pragma  can  appear  only  at  the  place  of  a  declarative 
item  In  a  declarative  {jart  or  package  specification;  the 
generic  to  which  it  applies  must  have  been  declared  by  an 
earlier  declarative  item  of  the  same  declarative  pairt  or 
package  specification. 

■  Any  generics  appearing  in  Apex  interface  views  must  be 
shared,  since  the  compiler  cannot  access  the  generic  body 
to  use  as  a  template  for  coding  replicated  instantiations. 

References 

■  generic  instantiation,  LRM  12.3 

■  generic  package,  LRM  12.1 

■  generic  subprogram,  LRM  12.1 

■  simple  name,  LRM  4. 1 

Pragmas  lmport_Function,  lmport_Object,  and  lmport_Procedure 

Associates  an  Ada  name  with  the  global  symbol  for  a  non-Ada 

subprogram  (function  or  procedure)  or  object  so  that  an  Ada 

subprogram  can  call  the  subprogram  or  reference  the  object. 

The  syntax  is: 


pragma 

IKP0RI_rUMCZZ01l 

( (urmuiikL 

->1 

iatmrBal_naam 

[EXTEIOiaL 

->1 

“  •xt«mBi_najD«’’  ] 

(. 

[ PARAKETER_TXPES 

->1 

param0tmr_tYpm_list] 

(RXSU1.T_TTPE 

->1 

tYpm_aiark'] 

(KECBAMXSH 

->1 

macbaaimm_li8t] ) ; 

pra^M 

INPORI_OBJECT 

( 1 IMTCRIIAL  <■>]  inteniai_naB« 

(r 

(EZTElUfAL~>]  " 0xtmrBal_nam»''  ]  )  ; 

pragma 

INPORT_PItOCESUIIE 

(  [IRERHAL 

->J 

iBtarnal_oama 

[EZTERHAL 

->1 

"  mxtarnal_aama''  ] 

1, 

(  PA1U1IETER_TXPE8 

->1 

paramatmr_typa_list] 

i, 

[MECHANISM 

“>1 

niacbaaism_li8t]  ) ; 

Arguments 

■  Zntsrnal:  The  Ada  simple  name  of  the  non-Ada  subpro¬ 
gram  or  object  to  be  Imported. 
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■  External:  An  optional  string  literal  that  specifies  the  global 
symbol  name  to  be  created  by  the  Ada  compiler.  Since  other 
languages  may  enforce  non-Ada-compatible  naming  con¬ 
ventions,  the  external  sfymbol  may  differ  from  the  Internal 
subprogram  or  object  name.  If  an  external  name  is  not 
spedfled,  the  Internal  name  Is  used  for  the  symbol  name. 

■  ParaMtar_T7pas:  A  parenthesized,  comma-separated  list 
of  type  and/or  subtype  names  that  describes  the  param¬ 
eter-type  profile  of  an  imported  subprogram.  If  the  subpro¬ 
gram  has  no  parameters,  the  list  can  consist  of  the  single 
word  Null.  This  optional  argument  may  be  required  when 
the  Internal  argument  specifies  an  overloaded  subprogram. 
See  “Usage,”  below. 

■  R«sult_T7p«:  The  restilt-type  profile  of  an  imported 
function.  This  optional  argument  may  be  required  when  the 
Internal  argument  specifies  an  overloaded  function.  See 
“Notes,"  below. 

■  Machanlsa:  A  parenthesized,  comma- separated  list  of 
parameter -passing  mechanisms  for  the  p)arameters  passed 
by  a  subprogram.  If  the  imported  subprogram  has  parame¬ 
ters,  then  the  Mechanism  argument  is  required:  otherwise, 
do  not  include  Mechanism.  There  must  be  a  one-to-one 
correspondence  between  the  paissed  parameters  and  the 
mechanisms.  The  supported  mechanisms  are: 

□  Value:  The  corresponding  parameter  is  passed  by  vadue. 

Note:  When  interfacing  with  C  or  C++,  only  scalars  can  be 
passed  by  value;  Mechanism  must  always  be  Value  and 
the  corresponding  Ada  parameter  must  be  an  in  parameter 
for  scalars. 

□  Reference:  The  corresponding  parameter  is  passed  by 
reference;  that  is,  its  address  is  passed.  This  applies  to 
records  aind  arrays  in  C  and  C++  and  to  C++  constaint 
reference  ptauameters. 

If  all  of  the  Imported  subprogram’s  parameters  au-e  passed 
with  the  same  mechanism,  you  cam  specify  a  single  occur¬ 
rence  of  the  mechamism  without  parentheses. 
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Pragmas:  Pragmas  lmport_Functlon,  lmport_Object,  and  lmport_Procedure 


Usage 

Use  the  import  pragma*  to  suppfy  more  information  about  a 
non-Ada  subprogram  specified  with  pragma  Interface  or  a  non- 
Ada  object  to  be  referenced  by  Ada  code. 

Every  imported  subprogram  must  be  described  both  by  pragma 
Interface  and  by  an  Import  pragma,  in  that  order.  Pragma  Inter¬ 
face  is  ignored  there  is  no  corresponding  import  pragma,  or  if 
the  import  pragma  contains  errors. 

If  the  internal  Ada  subprogram  name  is  overloaded,  you  must 
supply  enough  information  for  the  compiler  to  determine 
unambiguously  which  subprogram  is  being  imported.  Specify 
the  Parameter_Types  (and/or.  for  functions,  the  Result  Type) 
so  that  the  compiler  can  construct  the  parameter-  and/or 
result-type  profile  of  the  subprogram. 


Ccattfon:  Accesses  to  non-Ada  objects  from  Ada  code  are  inher¬ 
ently  unscfe:  the  compiler  and  runtime  system  cannot  guarantee 
the  Integrity  of  such  Imported  objects.  It  is  the  developer's  re¬ 
sponsibility  to  ensure  that  the  code  that  accesses  an  imported  ob¬ 
ject  properly  Interprets  and  maintains  the  underlying  structure  of 
the  object 


Notes 

■  An  Impxsrt  The  pragma  can  appear  only  at  the  place  of  a 
declarative  item  in  a  declarative  part  or  package  spjecifica- 
tlon;  the  subprogram  or  object  to  which  it  applies  must 
have  been  declared  by  an  earlier  declarative  item  of  the 
same  declarative  part  or  package  specification. 

■  An  import  pragma  must  not  refer  to  a  generic  subprogram. 

■  An  imported  object  must: 

□  Not  be  in  a  generic  unit 

□  Be  a  variable  declared  at  the  outermost  level  of  a  library- 
package  specification  or  body 

□  Have  a  static  size;  that  is,  its  subtype  must  be  one  of; 

-  A  scalar  type  or  subtype 

-  An  array  subtype  with  static  index  constraints  whose 
component  size  is  static 

-  An  undiscriminated  record  type  or  subtype 
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■  To  assign  an  impiorted  object  a  defavilt  initial  value,  use 
pragma  Initialize.  See  “Pragma  Initialize’’  on  page  92. 

References  for  Subprograms 

■  interface  to  other  languages,  LRM  13.9 

■  pragma  Interface,  LRM  13.9 

■  scalar  types,  LRM  3.3 

■  “Calling  a  Non-Ada  Subprogram  from  Ada”  on  page  6 

References  for  Objects 

■  limited  private  type,  LRM  7.4.4 

■  private  type,  LRM  7.4 

■  “Sharing  Global  Objects“  on  page  14 

Pragma  Initialize 

Specifies  that  default  initialization  be  carried  out  for  an 
Imported  variable  or  a  variable  referenced  by  an  address  clause. 
'The  syntax  is: 

prasM  ZMZTZJU.ZZK 
( aiapia_aaaa) ; 

Arguments 

■  simplejaamm-.  The  variable  to  which  default  initialization  is 
to  be  applied. 

Usage 

When  a  program  imports  a  variable  object  or  declares  a  variable 
with  an  address  clause,  the  compiler  assumes  that  this  veuiable 
previously  existed.  The  compiler  medtes  no  attempt  to  assign  a 
default  (initial)  value  to  this  variable,  because  the  veuiable 
might  already  contain  a  valid  value  or  might  be  given  an  initiad 
value  by  some  other  program.  By  default,  the  compiler  does  not 
perform  any  initialization  on: 

■  Variables  designated  by  address  clauses 

■  Imported  variable  objects:  see  “Pragmais  Import  Function. 
Import_Object,  and  Import_Procedure"  on  page  89 
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Pragma  Initialize  tells  the  compiler  to  assign  an  appropriate 
default  value  to  the  variable — for  example,  setting  pointers  and 
pxjlnter  fields  to  nuU,  record  fields  to  the  Initial  values  present 
In  the  record  type  definition,  and  discriminants  to  their  proper 
values.  Hence,  the  variable  must  not  have  an  explicit  Initial 
value. 

No  additional  storage  space  Is  allocated  because  valid  variables 
already  exist. 

The  referenced  variable  must; 

m  Have  been  declared  earlier  In  the  same  declarative  part 
a  Be  an  array  or  record 

■  Have  an  associated  address  clause,  or  it  must  have  been 
Imported  using  pragma  Import  Object  before  the  occur¬ 
rence  of  pragma  Initialize 

■  Not  have  an  explicit  Initial  value 

Example 

Pragma  Initialize  can  be  used  to  request  that  pointers  be  set  to 
Null  or  that  record  fields  be  given  some  starting  value. 

References 

■  address  clause.  LRM  13.5 

■  default  Initialization,  LRM  3.2.1 

Pragma  lnstance_Policy 

Specifies  how  to  generate  code  for  specific  instantiations  of  a 
generic.  The  syntax  Is: 

pragma  IRSTAMCX_POI.XCX 
( (IMSTAMTIATIOM  ->] 

(CODE  ->]  REPLICATED  |  SHARED); 

Arguments 

■  Instantiation:  The  simple  name  of  the  specific  instantia¬ 
tion  to  which  the  pragma  applies. 

■  Coda:  A  keyword  whose  value  can  be  Replicated  or  Shared. 
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Usage 

Use  pragma  Iiistance_Pollcy  to  specify  whether  to  generate 
replicated  or  shared  code  for  specific  instantiations  of  generics. 

The  following  example  Illustrates  the  use  of  the  pragma: 

"  EZCHiaKn_X  SDd  CZCBMm_R  us*  tb*  eoMon  sbar*d 
—  cod*.  CXCBlUKia_8  tts*s  its  om  r*plicat*d  cod*. 

g*n*rie 

tpp*  SoMtyp*  is  privat*} 
proeadur*  8Map(X,  X:  in  out  Sonotyp*); 
pragna  a*n*rie_Poliey(8Map,  Sbarad); 

proeadur*  Erehang*_R  is  n*M  8wap(SesMtyp*  >>  Raal); 
proeadur*  Cxeban9*_I  is  n*M  8wap(SoMtyp*  >>  Intagar); 
subtyp*  8  is  8tring(l. .100); 

proeadur*  Ezebang*_8  is  naw  8wap(Sa«*typ*  *>  S); 
pragma  Inatane*_Polie7(Bxebang*_S,  Raplicatad); 

Notes 

■  The  pragma  is  ignored  if  the  instantiation  refers  to  a  generic 
in  an  Apex  interface  view. 

■  The  pragma  and  the  named  instantiation  must  occur  within 
the  same  declarative  part  or  package  specification. 

■  The  instantiation  must  occur  before  the  preigma. 

■  If  the  Instantiation  eirgument  refers  to  several  preceding 
overloaded  subprogram  instantiations,  the  pragma  applies 
to  all  of  them. 

■  Only  one  pragma  Instance_Policy  can  be  appUed  to  each 
instantiation. 

References 

■  “Pragma  Generic_Pollcy"  on  pjage  88 

■  "Setting  Shared  or  Replicated  Generic  Policy"  on  page  22 

■  generic  instantiation.  LRM  12.3 

■  generic  piackage,  LRM  12.1 

■  generic  subprogram.  LRM  12.1 

■  simple  name.  LRM  4. 1 
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Pragma  Main 

Designates  an  Ada  main  tinlt  and  determines  some  aspects  of 
its  runtime  behavior.  The  syntax  is: 


prs9M  mza 

[  (  [0RBCT_DEaDI/X3C  -> 

(BBAP^SZIS  » 

[BoauioaczBO_zo  » 

[POSzz_caMn:.ZABT  » 

[nm^zvB_8CHDtn.zKO  -> 
[8ZaBAL_8TaaC_SZlB  -> 

(8T1U:k_8ZIS  ~  -> 

(Tll8K_PaZ0RZTZ_DKraUZ.T  •» 
( IA8K~8TaaC_8  Z  ZK.OKFIUILT 

■> 

(TZIIC_8LZCB  -> 


bool»mn_»xprmMmion, ] 
mtmtic_iBt0g»r_mxpr»mmion , ] 
boolmmn_mxpr»mmxoB, ] 
bool0mn_mxpr0mmion , ) 
bool0mn_»xpr0mmioa , ] 
mtMtic_int0gmr_mxprmmmion 
mtmtic_intmgmr_0xprmmmion , ] 
prioritY_mxpr0mmioB , ] 

mtmtic_iBtmgmr_0xpr0Bmion , ] 
durmt ioB_0xpr0mmioa\ )  ] ; 


Arguments 

■  0«tsct_D«adlock:  Specifies  whether  the  Rational  Ada 
runtime  system  should  diagnose  deadlock  situations  in  the 
program.  If  True,  the  nmtlme  system  will  print  a  diagnosis 
of  what  is  causing  the  tasks  to  block  when  deadlock  occurs. 
If  False,  the  program  simply  hangs.  The  default  is  False. 

■  B«sp_8i8«:  A  nonnegative  static  integer  expression  that 
specifies  how  much  space  to  allocate  for  the  heap,  in  bytes, 
when  the  main  unit  begins  execution.  If  this  argument  is 
specified,  no  additional  space  is  allocated  to  the  heap  after 
initialization;  requests  for  more  heap  space  raise  Storage- 
_EiTor. 

If  not  specified,  heap  space  is  allocated  dynamically  as 
needed  until  spiace  is  exhausted  and  Storage  Error  is 
raised. 

■  Nonblocklng_Io:  Specifies  whether  I/O  should  block  all 
tasks  in  the  program.  If  True,  only  the  task  performing  the 
I/O  blocks;  if  False,  the  entire  program  blocks.  For  a 
description  of  limitations  and  operation,  see  "I/O  in  Tasking 
Programs"  on  page  34  and  "Using  Blocking  and 
Nonblocking  I/O"  on  page  58.  The  default  is  Fadse. 
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■  Posiz^CoiQillaiit:  Specifies  whether  certain  behavior 
described  by  the  IEEE  Portable  Operating  System  Interface 
(POSDC)  is  required.  If  True,  the  following  operationad  char- 
acterlstjrs  of  programs  compiled  and  linked  under  Rational 
Apex  are  affected: 

□  The  program  can  control  only  those  UNIX  signals  explic- 
itty  allowed  by  POSIX.5  3.3.3. 1  (those  not  “reserved  for 
the  Ada  implementation”). 

a  The  program  caimot  install  an  interrupt -entry  task  to 
handle  UNIX  signals  that  the  runtime  system  uses,  nor 
can  it  install  both  an  interrupt-entry  task  and  an  Ada 
procedural  signal  handler  for  the  same  signal  (POSIX.5 
3.3.2.1(9631). 

□  The  default  values  for  the  Form-parzuneter  fields  in  the 
Ada-predefined  I/O  packages  are  the  POSIX.5  values 
rather  than  the  Apex  values,  as  described  in  “Field 
Defaults”  on  page  50. 

The  default  is  True. 

■  Preaaptiva^Scheduling:  Specifies  whether  preemptive 
(asynchronous)  task  scheduling  takes  place.  If  True,  all 
tasks  spawned  by  the  main  program  are  scheduled  preemp¬ 
tively.  The  default  is  False.  Task  scheduling  is  described  in 
Chapter  5.  “Ada  Tasking  in  UNIX." 

■  Si9nal_Stack_Sls*:  An  integer  expression  greater  than  or 
equal  to  2,048  (2  Kb)  that  specifies  the  size  of  the  signal 
stack,  in  bytes.  The  Ration^  Ada  runtime  system  uses  this 
stack  for  handling  runtime  signals,  and  the  debugger  uses 
this  stack  for  special  type  display.  If  not  specified,  the 
default  signal  stack  size  is  64  ?Cb.  When  the  program  is  run 
under  the  debugger,  the  default  stack  size  is  increased  to 

2  Mb. 

■  Stack_Size:  A  static  integer  expression  greater  than  or 
equal  to  2,048  (2  Kb)  that  specifies  the  size  of  the  main  task 
stack,  in  bytes.  If  not  specified,  the  default  stack  size  is 

2  Mb. 

■  Ta8k_Priorit7_Dafault:  An  expression  of  type  System- 
. Priority  that  specifies  the  priority  for  any  task  without  a 
pragma  Priority.  The  default  is  the  same  as  the  main  task's 
priority;  if  the  main  task  is  not  given  a  priority,  the  default 
is  127. 
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m  Taak_8tack_Siss_0«fault:  A  static  Integer  expression 
greater  than  or  equal  to  2,048  (2  Kb)  that  specifies  the  size, 
in  bytes,  of  the  stack  for  any  task  without  a  ‘Storage  Slze 
representation  clause.  The  default  is  64  Kb. 

m  TiM_Slle«:  A  nonnegative  expression  of  type  Standaird- 
.Duration  that  determines  the  quantity  of  time  to  allocate  to 
an  executing  task.  By  de£aiult.  or  if  the  value  is  zero,  no  time 
slicing  is  used.  This  has  an  effect  only  in  conjunction  with 
preemptive  scheduling:  otherwise,  it  is  ignored. 

Usage 

Use  pragma  Main  after  the  end  of  the  mut  body  of  any  pa¬ 
rameterless  bbrary-unit  procedure  to  designate  it  as  a  main 
program. 

Pragma  Main  can  have  two  effects.  It: 

■  Causes  the  unit  to  be  linked  automatically  if  it  is  in  the 
directory  or  view  for  which  you  have  requested  linking: 
main  units  without  pragma  Main  are  not  linked  unless 
explicitly  requested. 

■  Permanently  specifies  the  size  of  various  code  sections  and 
the  mode  of  operation  for  the  executable  program  resulting 
from  a  link. 

Example 

Use  pragma  Main  as  shown: 

proe«dur«  Show_Msin  is 
b«9in 

I>e_8eMtliln9; 

•nd  Sbo*«_llalii; 

pragma  Main  (8tack_SiBa  »  10*1024);  — Change  to  10  Kb 

Notes 

■  All  arguments  can  be  specified  using  Apex  session  switches 
to  change  the  options  dynamically  at  runtime.  The  switches 
have  the  same  names  as  the  arguments,  in  all  uppercase, 
with  the  prefix  APEX_.  Explicit  use  of  am  argument  on 
pragma  Main  overrides  the  switch  values. 
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References 

■  library  unit,  LRM  10. 1 

■  main  program,  LRM  10.1 

■  heap  and  stack  allocation,  “Miscellaneous  Memory  Manage¬ 
ment”  on  page  64 

Pragma  Must_Be_Con8trained 

Indicates  w4iether  formal  private  and  limited  private  types 
within  a  generic  formal  part  must  be  constrained  or  have 
default  values.  The  syntax  Is: 

pragM  MUST_BK_COHSTItXZllED 
(eoaditioa_ii«t) } 

Arguments 

■  coadltion_l±Mt:  A  comma- separated  list  of  conditions 
that  specifies  a  set  of  types  and  whether  each  set  must  be 
constrained  or  have  defhult  values.  Each  element  of  the 
condition  list  has  the  format: 

Icoaditioa  ■>]  typm_id_limt 
where: 

a  eoaditioa:  Can  be  either  YES  or  NO.  If  omitted,  the 
default  Is  YES.  Determines  the  settuig  for  all  types  in  the 
following  typ>e  ID  list. 

□  typm_id_limt'.  A  comma-separated  list  of  formal  private 
or  limited  private  types.  These  types  must  be  defined  in 
the  same  formal  part  as  the  pragma. 

Usage 

Use  pragma  Must_Be_Constralned  to  specify  how  you  intend  to 
use  the  formal  parameters  In  a  generic  specification. 

Each  condition  controls  the  fypes  In  the  following  type  ID  list, 
until  the  next  occurrence  of  a  condition.  Consider  this  example: 

pragas  Must_Ba_Conatrainad 

(T3rp«_l»  «0->rypa_2,  Typ«_3r  T*S->Typ«_4,  Typ«_5); 

At  the  beginning  of  the  list,  a  condition  is  not  specified,  so  yes 
is  assumed;  hence,  Type_l  Is  constrained.  MO  controls  the 
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following  type  ID  list,  which  includes  Type_2  and  Type_3; 
hence,  they  are  unconstrained.  XES  controls  the  remaining  type 
ID  list,  so  Type_4  and  Type_5  are  constrained. 

Notes 

If  the  condition  NO  is  specified,  any  use  in  the  body  that 
requires  a  constrained  type  will  generate  a  semantic  error.  If 
YES  is  specified,  any  instantiations  that  contain  actual  param¬ 
eters  that  require  constrained  types  will  generate  semantic 
errors  if  the  actual  parameters  are  not  constrained  and  have  no 
default  values. 

References 

■  constrained  private  type,  LRM  7.4.2 

■  generic  formal  type,  LRM  12 

■  matching  rules  for  formal  private  types.  LRM  12.3.2 

■  limited  private  type,  LRM  7.4.4 

■  private  type  as  generic  formal  type.  LRM  12. 1 .2 

Pragma  Signal_Handler 

Installs  an  Ada  procedure  as  a  UNIX  signal  handler.  The  syntax 
is: 

SiaNAI._BJUn)Xjn 
(HJUac  *>  miMplm_uamm , 

SIOKAL  •>  intmgf*r_mxpr»mmioB) ; 

Arguments 

■  Nsim:  The  simple  Ada  name  of  the  signal-handling 
procedure. 

■  Signal:  A  nonstatic  integer  expression  specifying  the  UNIX 
slgnsd  number  to  be  handled  by  the  specified  procedure. 

Usage 

Elaboration  of  the  praigma  has  the  effect  of  installing  the  spec¬ 
ified  procedure  as  a  signal  handler  for  the  given  signal;  subse¬ 
quent  occurrences  of  the  specified  signal  will  cause  the 
specified  procedure  to  be  Invoked 
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The  pragma  and  the  procedure  body  must  occur  in  the  same 
declarative  part,  with  the  pragma  following  the  procedure  body. 
This  prevents  the  Installation  of  a  procedure  whose  body  has 
not  yet  been  elaborated. 

See  “Ada  Procedural  Signal  Handlers"  on  page  43  for  details  on 
the  construction  of  the  procedure. 

References 

■  simple  name,  LRM  4. 1 

■  declarative  part.  LRM  3.9 

Pragma  Suppress_AII 

Suppresses  all  permitted  runtime  checks.  The  syntax  is: 

pragma  SUPPRXS8_AIJ,; 

Arguments 

None. 


Usage 

Use  pragma  Suppress_All  to  create  the  same  effect  as  all  of  the 
following: 


pragma  Suppraas 
pragma  Suppraaa 
prwfma  Suppraaa 
pragma  Suppraaa 
pragma  Suppraaa 
pragma  Suppraaa 
pragma  Suppraaa 
pragaw  Suppraaa 
pragma  Suppraaa 


(Accaaa_Cback) ; 
(Diacrimiaant_Cback) ; 
(DiviaioB_Cback) ; 
(ElaborabioB_Cback) ; 

( Iiidar_Cbaek) ; 
(I«ngtb_Cbaek) ; 
(Ovarflew_Cbaek) ; 

( Storaga_Cback ) ; 

( Ranga_Cback ) ; 


Notes 

■  Pragma  Suppress  AU  has  no  effect  in  a  package 
specification. 

■  The  pragma  must  appear  Immediately  within  a  declarative 
part. 
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References 

■  suppressing  c±Lecks.  LRM  1 1. 

Pragma  Suppre88_Elaboration_Checks 

Suppresses  all  elaboration  checks  in  a  given  compilation  unit. 
The  syntax  is: 

prasM  8uppra«a_Blsboration_Cb«c>ca; 

Arguments 

None. 

Usage 

Use  pragma  Suppress_Elaboration_Checks  after  the  end  of  the 
unit  body  of  any  compilation  unit  to  suppress  elaboration 
checks  for  all  subprograms  in  that  unit.  This  is  equivalent  to 
placing  a  named  pragma  Suppress  (Elaboration  Check)  on 
each  subprogram  in  the  unit. 

References 

■  suppressing  checks.  LRM  11.7 


Attributes 


Table  10-3  summarizes  all  implementation -defined  attributes 
in  Rational  Ada.  Each  attribute  is  described  in  more  detail  in 
the  following  subsections. 


Table  10-3  Implementation-Dejlned  Attributes 


Attribute 

Meaning 

’CompUerKey 

Identifies  the  compiler  used  to  generate  code 
for  the  specified  object 

‘Com  pUerVersion 

Yields  the  version  of  the  compiler  used  to  gen¬ 
erate  code  for  the  specified  object 

DopeAddress 

Yields  the  address  of  the  dope  vector  for  an 
array  object 
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TaMe  10-3  /mptemantatton-O^ncd  Attribute*  (Continuetl) 


Attribute 

Meaning 

■Dope_Sl2e 

Yields  the  size  of  the  dope  vector  for  an  array 
object 

’Entiy_Number 

Uniquely  identifies  an  entry  or  generic 

'Homogeneous 

Specifies  whether  objects  in  a  coUecUon  are  of 
uniform  size 

’Type_Key 

Uniquely  identifies  a  type 

’Compiler_Key 

For  a  prefix  N  that  denotes  the  name  of  an  entity,  M '  Compiler- 
_K«y  yields  the  full  pathname  of  the  compiler  key,  which  indi¬ 
cates  the  compiler  that  was  used  to  generate  code  for  the  unit 
containing  the  definition  of  N. 

The  entity  named  by  N  can  be  a  program  unit  (package,  subpro¬ 
gram.  task,  or  generic),  an  object  (variable,  constant,  named 
number,  or  parameter),  a  type  or  subtype  (but  not  am  incom¬ 
plete  type),  or  an  exception. 

The  value  returned  by  this  attribute  is  of  type  String;  for 
example,  "/rnv_hoBe/k«y«/»ds_rational_rs6k_aix" . 

This  attribute  can  be  used  for  runtime  detection  of  Incompati- 
biUtles  In  data  representation.  It  typically  Is  used  when  passing 
messages  over  a  network  to  ensure  that  the  reader  and  writer 
agree  on  how  to  interpret  the  message.  See  also  Compiler - 
Version. 

’Compiler_Version 

For  a  prefix  N  that  denotes  the  name  of  an  entity,  N '  Compiler- 
_V«r«ion  yields  the  version  of  the  compiler  that  was  used  to 
generate  code  for  the  unit  containing  the  definition  of  N. 

The  entity  named  by  N  can  be  a  program  unit  (package,  subpro¬ 
gram,  task,  or  generic),  an  object  (variable,  constant,  named 
number,  or  fiarameter),  a  type  or  subtype  (but  not  an  incom¬ 
plete  type),  or  am  exception. 
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The  value  returned  by  this  attribute  Is  of  type  string;  for 
example,  ‘11.4.0*. 

This  attribute  can  be  used  for  runtime  detection  of  incompati¬ 
bilities  In  data  representation.  It  typically  Is  used  when  passing 
messages  over  a  network  to  ensure  that  the  reader  and  writer 
agree  on  how  to  interpret  the  message.  See  also  ’Compiler  Key. 

’Dope_Address 

For  an  array  object  A.  A'  Dop*_Address  yields  the  address  of 
the  dope  vector  that  describes  A.  The  value  is  of  tyjse  System- 
•Address.  If  the  object  denoted  by  A  has  no  dope  vector,  this 
value  is  0. 

This  attribute  can  be  used  in  conjunction  with  ’Dop)e_Size  for 
retrieving  Information  about  the  object,  as  when  reconstructing 
the  array  when  passing  messages  over  a  network.  See  "Dope 
Vectors"  on  page  76  for  additional  information. 


’Dope_Size 

For  an  array  object  A.  A '  Dope^Sise  yields  the  size  in  bits  of  the 
dope  vector.  The  value  is  of  type  UnlversaJJnteger. 

A  positive  value  is  always  returned,  whether  or  not  the  object 
denoted  by  A  has  a  dope  vector.  Use  ’Dope_Address  to  deter¬ 
mine  whether  the  dop>e  vector  actually  exists. 

This  attribute  can  be  used  for  retrieving  information  about  the 
object,  as  when  reconstructing  the  array  when  passing 
messages  over  a  network.  See  "Dojje  Vectors"  on  page  76  for 
additional  Information. 

’Entry_Number 

For  a  prefbc  E  that  denotes  a  task  entry  or  generic  formal 
subprogram,  E '  Entry^Muabar  yields  a  Universal_Integer  veilue 
that  uniquely  identifies  the  entity  denoted  by  E. 

’Homogeneous 

For  a  prefix  T  that  denotes  £ui  access  type,  T '  HomogeDeous 
yields  a  Boolean  value.  The  vadue  returned  Is  True  if  aJl  objects 
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in  the  collection  will  always  have  the  same  constraints.  The 
converse,  however,  is  not  true. 

Applying  this  attribute  to  a  type  that  is  not  an  access  value  is  a 
semantic  error. 


Note  that  the  attribute  is  a  property  of  the  type,  not  of  the 
subtype.  Thus,  for  any  access  type  T,  T '  Homogeneous  yields  the 
same  value  as  T  ‘  Base '  Homogeneous. 

For  example: 


type  T1  is  access  String  (1..10); — 
type  T2  is  access  String; 
type  T3  is  new  T2  (1  ..  10); 
type  T4  is  new  Tl; 


T1 ‘ Homogeneous ~True 
T2 'Homogeneous •False 
T3 'Homogeneous*False 
T4 ‘Homogeneous~True 


At  the  implementation  level,  the  attribute  indicates  whether 
constraint  information  is  stored  with  allocated  objects. 


’■rVpe_Key 

For  a  prefix  T  denoting  a  type  name,  T  ’  Typo_Key  yields  a  string 
that  unique^  identifies  type  T.  This  attribute  typically  is  used 
when  passing  messages  of  a  given  type  over  a  network  to  ensure 
that  the  reader  and  writer  agree  on  the  type  to  use  when  inter¬ 
preting  the  message. 

Attributes  of  Numeric  lypes 

This  section  lists  the  values  returned  by  attributes  that  apply 
to  integer  types. 

integer  Types 

The  attributes  that  appty  to  integer  types — naunely,  'First.  Last, 
and  'Size — ^yield  the  values  shown  below  for  the  predefined  base 
type: 


Tattle  10-4 

Attribute  Valueefor  Integer  Types 

Attribute 

Value 

'First 

-23* 

'Last 

23*-1 

'Size 

32 
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Packages  Standard  and  System 


This  section  contains  the  spedflcations  for  packages  Standard 
and  System. 

Package  System  (LRM  13.7) 

Pselcse*  SystMi  is 

typ*  Jkddrsss  Is  privsts; 

typs  Hsm  is  (lts6000_Aix); 

8ystsa_NsM  :  eenstsnt  Msm  Sparc_Suno8; 
Stors9s_Uait  :  eonstsst  8; 

NsaMry_Siss  t  coastsnt  ■f(2  **  31)  -  1; 

Mio_Xnt  :  constant  -(2  **  31); 

Nss_Int  :  constant  :>  -¥{2  **  31)  -  1; 

Nax^Oigits  t  constant  15; 

Maz_Maatisaa  t  constant  31; 

Pias_Oslta  t  constant  1.0  /  (2.0  **  31); 

Tick  t  constant  :*  1.0  /  100.0; 

subtypo  Priority  is  Intogor  range  0  . .  255; 

Assortion_Error  :  oxcoption; 

function  To_Addross  (Value  :  Integer)  return  Address; 
function  To_Integer  (Value  :  Address)  return  Integer; 

function  "■t'''  (Left  :  Address;  Right  :  Integer) 
return  Address; 

function  (Left  :  Integer;  Right  :  Address) 

return  Address; 

function  (Left  :  Address;  Right  :  Address) 

return  Integer; 

function  (Left  :  Address;  Right  :  Integer) 

return  Address; 

function  "<'*  (Left,  Right  :  Address)  return  Boolean; 
function  "<•"  (Left,  Right  :  Address)  return  Boolean; 
function  *>'  (Left,  Right  :  Address)  return  Boolean; 
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fuaotioD  (X<*£t,  Right  t  Rddrass)  raturn  Boolean; 

—  The  functions  abovo  aro  unaignod  in  nature.  Heitber 

—  Muaarie_Brror  nor  Conatraint_Error  will  aver  be 

—  propagated  by  these  functions. 

—  Consequently, 

—  To__Addresa  ( Integer  *rirst)  > 

—  To_Addresa  ( Integer ‘  lest ) ; 


—  and 

—  To^Addreas  (0)  <  Ta_Address  (-1); 

—  The  unsigned  range  of  Address  includes  values  that 

—  are  larger  than  those  iaplied  by  MeBory_Size. 

Address_Zero  :  constant  Address; 
lfull_Addresa  :  constant  Address; 

■o_Addr  :  constant  Address; 

private 

type  Address  is  new  Integer; 

Address^Zero  :  constant  Address  :<•  0; 

Rull_Address  :  constant  Address  0; 

Me_Addr  :  constant  Address  0; 

pragna  Suppress (Elaboration_Cbeck,  On  ■>  System. "t” ) ; 
pragma  Suppress (Elaboration_Cback,  On  •>  System."-"); 
pragma  Suppress (Elaberation_Check,  On  >>  System. ">”) ; 
pragma  Suppress(E  «boration_Cbeek ,  On  *>  System ; 
pragma  Suppress ( .iberation_Check,  On  »  System.  "<”); 
pragma  Suppress (Xxaboration_Cbeck,  On  ->  System. ; 
pragma  Suppress (Blaboratien_Cbeek, 

On  *>  System. To_Address ) ; 
pragma  Suppress ( Blaberation_Check , 

On  «>  System. To_Integer) ; 

pragma  Xnline(System. "t”) ; 
pragma  Xnline(8ystem. ; 
pragma  Inline  (System. ; 
pragma  Inline  ( System. ; 
pragma  Inline(System. ”<") ; 
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pra^a  ZBllBa<8yataa. ’<■*') ; 
pragM  Zalina (8rataa.Se_Addxaaa); 
pragaa  Zalina ( 8pataa.To_Znta9ar ) ; 

and  Syataai 

Package  Standard  (LRM  Annex  C) 

paekaga  8tandard  la 

tppa  *Ualvarnal_Inta9ar*  la  ... 
typa  *Ualvaraal_Raal*  la  ... 

tjpa  *Ualvaraal_Plxad*  la  _ 

typa  Boolaan  la  (Palaa,  Trua); 

typa  Zntagar  la  raaga  -2147483648  ..  2147483647; 
typa  Float  la  dlgita  6 

raaga  -((2.0  **  128)  -  (2.0  **  104))  .. 

((2.0  ••  128)  -  (2.0  **  104));—  about  3.4E-t-38 
typa  Loag_rioat  la  dlgita  15 

raaga  -((2.0  **  1024)  -  (2.0  **  971))  .. 

((2.0  **  1024)  -  (2.0  **  971));  —  about  1.8E-t-308 

aubtypa  Natural  la  Zntagar  raaga  0  ..  2147483647; 
aubtypa  Poaitlva  la  Zntagar  raaga  1  ..  2147483647; 
typa  Duration  la  dalta  0.000061035156 
raaga  -131072.00000000  .. 

0131071 .9999389648437500000000; 
typa  Charaetar  la  ... 

paekaga  Aaeli  la . . . 

typa  String  la  array  (Poaitlva  raaga  <>)  of  Character; 
Conatralat_Error  t  azcaption; 
auMrie_Error  :  axeaptlon; 

Storaga_Error  :  azcaption; 

Tanking_Error  :  axoaption; 

Prograa_Error  :  axeaptlon; 
typa  *Anytypa*  la 
record 
null; 

end  record; 
and  8tandard; 

The  following  table  shows  the  sizes  of  predefined  integer  and 
floating-point  typ>es: 
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ToJMe  10*5  SiM^M  of  PmUfflnmd  Numeric  Type* 


Ada  Type  Name 

Siae 

Integer 

32  bits 

Float 

32  bits 

Long;_Float 

64  bits 

Fixed-point  types  are  implemented  using  32  bits. 

Floating-point  types  are  implemented  according  to  the  IEEE 
Standard  for  Binary  Floating-Point  Arithmetic  (ANSI/IEEE  Std. 
754-1985). 

Standard.Duration  is  a  32-bit  fixed-point  type  with  a  delta  of 
2-U. 

Representation  Clauses 


This  section  discusses  limitations  on  representation  clauses  in 
the  following  categories; 

a  “Representation-Clause  Error  Handling"  on  page  108 
m  “Length  Clauses"  on  page  109 

■  "Record  Representation  Clauses  (LRM  13.4)"  on  page  110 
m  “Enumeration  Representation  Clauses  (LRM  13.31"  on 

page  1 10 

■  "Change  of  Representation  (LRM  13.6)”  on  page  110 
For  related  information,  see  Chapter  9.  “Sizes  of  Objects." 

Representation-Clause  Error  Handling 

Normally,  an  invalid  representation  clause  causes  an  error  at 
compile  time  and  prevents  successful  compilation. 

Several  Apex  context  switches,  however,  allow  you  to  specify 
whether  to  treat  certain  classes  of  invalid  representation 
clauses  as  nonfatal  errors  that  allow  successful  compilation 
rather  than  as  errors.  See  Appendix  A.  "Switches,"  cind  Using 
Rational  Apex  for  details  on  the  following  switches: 
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■  Ignore_InvaIld_Rep_Specs:  Affects  the  handling  of  both 
Invalid  and  unsupported  representation  specifications. 

■  Ignore_Unsupported_Rep_Specs;  Affects  the  handling  of 
unsupported  representation  specifications  only. 

Length  Clauses 

Length  clauses  are  never  allowed  on  derived  record  types; 
otherwise,  length  clauses  are  supported  by  Rational  Ada  as 
follows: 

m  The  value  of  a  ’Size  attribute  must  be  a  positive  static 
integer  expression.  It  must  be  greater  than  or  equal  to  the 
minimum  size  necessary  to  store  the  largest  possible  value 
of  the  type.  ‘Size  attributes  are  supported  for  all  scalar  and 
composite  types  with  the  following  restrictions: 


Table  10-6  *S(sc  Attribute  Restrictions 


Types 

Legal  Attribute  Values 

Access  and  task 

32 

Composite 

Must  not  imply  compression  of  composite 
components;  such  compression  must  have 
been  explicitly  requested  using  a  length  clause 
or  pragma  Pack  on  the  component  type 

Discrete 

Less  than  or  equal  to  32 

Fixed-point 

Less  than  or  equal  to  32 

Floating-point 

Can  specify  only  the  size  the  type  would  have 

If  there  were  no  clause:  therefore,  the  only 
legal  values  are  32  and  64 

■  ’Storage_Slze  attributes  are  supported  for  access  and  task 
types.  The  value  given  by  a  ’Storage_Size  attribute  can  be 
any  Integer  expression,  and  it  is  not  required  to  be  static. 

■  'Small  attributes  are  supported  for  fixed-point  types.  The 
value  given  by  a  'Small  attribute  must  be  a  positive  static 
real  number  that  cannot  be  greater  than  the  delta  of  the 
base  type.  It  need  not  be  a  power  of  2. 
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Enumeration  Representation  Ciauses  (LRM  13.3) 

Enumeration  representation  clauses  are  supported  with  the 
following  restriction: 

R  The  allowable  values  for  an  enumeration  clause  range  from 
Integ-r’Flrst  to  Int^er'Last. 

Record  Representation  Clauses  (LRM  13.4) 

Both  full  and  partial  representation  clauses  are  supported  for 
both  discriminated  and  undiscriminated  records.  Record 
component  clauses  are  not  allowed  on: 

■  Array  or  record  fields  whose  constraint  involves  a  discrimi¬ 
nant  of  the  enclosing  record 
a  Array  or  record  fields  whose  constraint  is  not  static 

The  static  simple  expression  in  the  alignment  clause  part  of  a 
record  representation  clause — see  the  Ada  LRM  13.4  (4) — must 
be  a  power  of  2  with  the  following  limits: 

1  <■  statie_si»vl«_«spr%ssion  <*  i6 

The  size  specified  for  a  discrete  field  in  a  component  clause 
must  not  exceed  32  bits. 

ChanciA  of  Representation  (LRM  13.6) 

Change  of  representation  is  supported  wherever  it  is  implied  by 
support  for  representation  specifications.  In  peulicular,  type 
conversions  between  array  types  may  cause  packing  or 
unpacking  to  occur:  conversions  between  related  enumeration 
types  with  different  representations  may  result  in  table- lookup 
operations. 

Implementation-Generated  Names 


The  Ada  LRM  allows  for  the  generation  of  names  denoting 
implementation-dependent  components  in  records.  No  such 
names  are  visible  to  the  user  for  Rationad  Ada. 
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Address  Clauses  (LRM  13.5) 


Address  clauses  cannot  be  appUed  to  task  types.  No  other 
restrictions  are  placed  on  address  clauses. 

An  address  clause  can  be  attached  to  a  task  entry  only  when 
the  task  entry  Is  used  for  signal  (interrupt)  catching;  however. 
In  this  case,  the  task  entry  must  be  available  at  the  time  of  the 
signal.  See  the  discussion  of  pragma  Sigrud_Handler  on 
page  99  and  “Interrupt-Entry  Tasks”  on  page  40  for  additional 
information. 

Vadues  of  address  clauses  are  not  checked  for  validity.  No  check 
is  made  to  determine  whether  an  address  clause  cause.:;  the 
overlay  of  objects  or  of  program  units. 

Unchecked  Programming 


Unchecked  Storage  Deallocation  (LRM  13.10.1) 

Unchecked  storage  deallocation  Is  Implemented  by  the  Ada 
LRM-defined  generic  function  Unchecked_Deallocation.  This 
procedure  can  be  instantiated  with  an  object  type  and  its 
access  type,  resulting  in  a  procedure  that  deallocates  the 
object's  storage.  Objects  of  any  type  can  be  deallocated. 

The  storage  reserved  for  the  entire  collection  associated  with  an 
access  type  is  reclaimed  when  the  progreun  exits  the  scopie  in 
which  the  access  type  is  declared.  Placing  an  access-type  decla¬ 
ration  within  a  block  can  be  a  useful  implementation  strategy 
when  conservation  of  memory  is  necessary  within  a  collection. 
Space  on  the  free  list  is  coalesced  when  objects  are  deallocated. 

Erroneous  use  of  dangling  references  may  be  detected  in 
certain  cases.  When  detected,  the  Storage_Error  exception  is 
raised.  Deallocation  of  objects  that  were  not  created  through 
allocation  (that  is,  through  Unchecked  Conversion)  may  also 
be  detected  in  certain  cases,  also  raising  Storage  Error. 

Unchecked  Type  Conversion  (LRM  13.10.2) 

Unchecked  type  conversion  is  implemented  by  the  generic 
function  Unchecked_Conversion  defined  by  the  Ada  LRM.  This 
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function  can  be  Instantiated  with  source  and  target  types, 
resulting  in  a  function  that  converts  source  data  values  into 
target  data  values. 

Unchecked  type  conversion  moves  storage  units  from  the 
source  object  to  the  target  object  sequentially,  starting  with  the 
lowest  address.  Transfer  continues  until  the  source  object  is 
exhausted  or  the  target  object  runs  out  of  space.  If  the  target  is 
larger  than  the  source,  the  remaining  bits  are  undefined. 
Depending  on  the  target-computer  architect,  the  result  of 
conversions  may  be  right-  or  left-justified. 

Restrictions  on  Unchecked  Type  Conversion 

The  following  restrictions  apply  to  unchecked  type  conversion: 

■  The  target  type  of  an  unchecked  type  conversion  cannot  be 
an  unconstrained  array  type  or  an  unconstrained  discrimi¬ 
nated  type  without  default  discriminants. 

■  Internal  consistency  among  components  of  the  target  type 
is  not  guaranteed.  Discriminant  components  may  contain 
illegal  values  or  be  inconsistent  with  the  use  of  those 
discriminants  elsewhere  in  the  type  representation. 

Input/Output  Packages 


The  Ada  language  defines  specifications  for  four  I/O  packages: 
Sequentlaljo.  Direct  lo.  Low  LevelJo.  and  Text  io.  The 
following  subsections  explain  the  implementation-dependent 
characteristics  of  those  four  packages  provided  with  Rational 
Ada. 

Sequentiaijo  (LRM  14.2.2  and  14.2.3) 

For  the  Read  procedure  of  Sequentlal  jo.  the  Data  Eiror  excep¬ 
tion  is  raised  only  when  the  size  of  the  data  read  from  the  file  is 
greater  than  the  size  of  the  out  parameter  Item. 

POSIX  Compliance 

The  Form  parameter  on  subprograms  in  Sequential  lo  is 
compliant  with  the  POSIX.5  standard  to  the  extent  described  in 
Chapter  7,  “Files  and  I/O." 
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Directjo  (LRM  14.2.4) 

Package  Dlrect_Io  may  not  be  instantiated  with  any  type  that  is 
either  an  unconstrained  array  type  or  a  discriminated  record 
type  without  default  discriminants.  A  semantic  error  is  reported 
when  an  attempt  is  made  to  install  any  unit  that  contains  an 
instantiation  in  which  the  actual  type  is  such  a  forbidden  type. 

For  the  Read  procedure  of  Direct  lo,  no  check  is  performed  to 
ensure  that  the  data  read  from  the  file  can  be  interpreted  as  a 
value  of  the  Element  Type. 

Specification  of  Package  Direct_lo  (LRM  1 4.2.5) 

The  declaration  of  the  type  Count  in  package  Direct  lo  is: 

typ*  Count  is  not*  Intogor  rang*  0  .  .  Intogor '  lAst  / 
EloMnt_Typ« '  Six* ; 

where  Element  Type  is  the  generic  formal  type  parameter. 

POSIX  Compliance 

The  Form  parameter  on  subprograms  in  Direct_lo  is  compliant 
with  the  POSIX.5  standard  to  the  extent  described  in  Chapter 
7.  “FUes  and  I/O.” 

Low-Level  Jo  (LRM  14.6) 

Package  Low  Level  lo  Is  not  provided  with  Rational  Ada. 

Text  Jo  (LRM  14.3) 

The  Text  io  default  input  and  output  files  are  associated 
with  the  UNIX  standard  input  and  standard  output  paths, 
respjectively. 

Specification  of  Package  Text  Jo  (LRM  14.3.10) 

The  declaration  of  the  type  Count  in  Text  io  is: 

typo  Count  is  now  intogor  rango  0  .  .  1_000_000_000 ; 

The  declaration  of  the  subtype  Field  in  Text  io  is: 

subtypo  riold  is  Intogor  rango  0  ..  Intogor 'Last; 
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File-Management  Operations 

The  operations  of  Get  and  Put  are  as  described  in  the  Ada  LRM. 

Data  written  using  Put  and  Put_Llne  is  not  interpreted  in  any 
fashion.  Data  written  using  Put_Line  Is  followed  by  the  line 
terminator  Ascii.  Lf. 

Data  read  using  Get  and  Get_Ltne  Is  not  interpreted  except  that 
the  line  terminator,  Ascii.Lf.  and  the  page  terminator.  Ascii.Ff, 
are  removed  from  the  input  stream. 

POSiX  Compliance 

The  Form  parameter  on  subprograms  in  Text  lo  is  compliant 
with  the  POS1X.5  standard  to  the  extent  described  in  Chapter 
7,  “Files  and  I/O." 

Other  Implementation-Dependent  Features 


Machine  Code  (LRM  13.8) 

Machine-code  insertions  are  not  supported  at  this  time. 
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